Affected stories

• 🌟 IOCOM-864: [App] Rimuovere logica del download
  subtask of
  • ⚡ IOCOM-813: Adottare il nuovo design system nella schermata di visualizzazione allegato di un messaggio IO
• 🌟 IOCOM-865: [App] Adattare UI visualizzazione allegato
  subtask of
  • ⚡ IOCOM-813: Adottare il nuovo design system nella schermata di visualizzazione allegato di un messaggio IO

Generated by 🚫 dangerJS against 6bf3b8c

Codecov Report

Attention: 89 lines in your changes are missing coverage. Please review.

Comparison is base (4b708e4) 47.35% compared to head (6bf3b8c) 47.35%.

@@            Coverage Diff             @@
##           master    #5428      +/-   ##
==========================================
- Coverage   47.35%   47.35%   -0.01%     
==========================================
  Files        1510     1512       +2     
  Lines       32076    32166      +90     
  Branches     7846     7860      +14     
==========================================
+ Hits        15190    15231      +41     
- Misses      16828    16876      +48     
- Partials       58       59       +1     

@Vangaorth I know it's still a draft PR, but just some notes after playing with it :)

• PDF Preview Screen: Unless we have different logic between the old and new screens, it's better to keep a single page and let the components do their job. In fact, each new UI chunk responds to the isExperimental value. For example, if you use HeaderSecondLevel (with react-navigation) the header title is rendered with Titillium in the legacy version and with the new (temporary) Readex in the new one.
• That said, I'd avoid the DS prefix because it's a way to separate the Design System pages from the others.
• For the failure/success screens, take a look at the OperationResultScreen. It's completely configurable and it's already tested in different environments. Do not add the new component DSInfoScreen... if possible.
• The new FooterWithButtons should be improved because it has spacing issues, as you can see from the attached screenshots. When there's the home indicator (iPhone X and up), the button is too close to the screen, but when we add a SafeAreaView, it's too distant. It's something we have to solve through some changes to the io-app-design-system library.

• PDF Preview Screen: Unless we have different logic between the old and new screens, it's better to keep a single page and let the components do their job. In fact, each new UI chunk responds to the isExperimental value. For example, if you use HeaderSecondLevel (with react-navigation) the header title is rendered with Titillium in the legacy version and with the new (temporary) Readex in the new one.
• That said, I'd avoid the DS prefix because it's a way to separate the Design System pages from the others.
• For the failure/success screens, take a look at the OperationResultScreen. It's completely configurable and it's already tested in different environments. Do not add the new component DSInfoScreen... if possible.
• The new FooterWithButtons should be improved because it has spacing issues, as you can see from the attached screenshots. When there's the home indicator (iPhone X and up), the button is too close to the screen, but when we add a SafeAreaView, it's too distant. It's something we have to solve through some changes to the io-app-design-system library.

1. Replaced with existing components (that have been updated in order to use the new DS if it is enabled)
2. That is a choice we made for the DS porting. As soon as the new DS replaces the existing one, we will remove legacy files and rename the new ones
3. Very good indeed, replaced
4. Will update the library as soon as a new release is made available